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Energy Object Context MIB 


Abstract 
This document defines a subset of a Management Information Base (MIB) 
for energy management of devices. The module addresses device 
identification, context information, and the energy relationships 
between devices. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7461. 


Copyright Notice 


Copyright (c) 2015 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


Parello, et al. Standards Track [Page 1] 


RFC 7461 Energy Object Context MIB March 2015 


Table of Contents 


1. Introduction: ull re Re ERA RUE URS IER See es See ens eR RUNE 2 
1.1. Energy Management Document Overview ....... eee ee ee ee ee ee eee 2 
1.2. Conventions Used in This Document .................. eee 3 

2. The Internet-Standard Management Framework ...................... 3 

3S2 TELM NOLO GY caus redux we ius YU DT e D S I varies ete suite que uo efe e dre a 4 

4. Architecture Concepts Applied to the MIB Module ................. 4 
4.1. Energy Object. IdentifriCatliORN. 4-5 Werne Unsere lotir eesti 8 
4.2.-Energy-Obgecet COnteXt v. Site RE I RU Erie RU EUREN e GU. RUE 9 
4,3. Links to Other Identifiers seres yopo T ete ea Care PRÉ Re E. 10 
4.4. Energy Object. Relationships ...2. 69e paaa eed oe Se: g RU LI 
4.5. Energy Object Identity Persistence ................... eee 12 

Bis MIB- Definitions D —-———————————————ÉÉ—— 12 

6. Security (Con$rOerdtiOnS 6. reine saser essa a lend oS SES ae SS? e x. 27 

Wl. LANA: GonsdderatlionS Sou edie eee aoe dw o. eU o alee See Ex UE E e ERLE Sue c e e Sle SESS 28 

SN 'UBeterences- Sons ER reuse ee SSMUS aren tae EASQUE NIIS UNE IDEE 29 
8.1. Normative References Lil. e we 9 b eg xU ees rn SEN 29 
8.2. Informative (References: xi... wg aa a a eae ESN a 30 

Acknowledgments; $e 4. ohare: ener a e E “ore Osu et arial feeb eere ere eer etna erie ters 31 

Authors” Addresses, ss tea eave ANRA in a Ea e envasis e Aa eyelet Mave ares 32 

1. Introduction 


The Energy Management (EMAN) standards provide a specification for 
Energy Management. This document defines a subset of a Management 
Information Base (MIB) for use with network management protocols for 
Energy monitoring of network devices and devices attached to the 
network and possibly extending to devices in the industrial 
automation setting with a network interface. 


The focus of the MIB module specified in this document is on the 
identification of Energy Objects and reporting the context and 
relationships of Energy Objects as defined in [RFC7326]. The module 
addresses Energy Object identification, Energy Object context, and 
Energy Object relationships. 


1.1. Energy Management Document Overview 


This document specifies the Energy Object Context (ENERGY-OBJECT- 
CONTEXT-MIB) and IANA Energy Relationship (IANA-ENERGY-RELATION-MIB) 
modules. The Energy Object Context MIB module specifies MIB objects 
for identification of Energy Objects, and reporting context and 
relationship of an Energy Object. The IANA Energy Relationship MIB 
module specifies the first version of the IANA-maintained definitions 
of relationships between Energy Objects. 
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Firstly, to illustrate the importance of energy monitoring in 
networks and, secondly, to list some of the important areas to be 
addressed by the Energy Management Framework [RFC7326], several use 
cases and network scenarios are presented in the EMAN applicability 
statement document [EMAN-AS]. In addition, for each scenario, the 
target devices for energy management, and how those devices powered 
and metered are also presented. To address the network scenarios, 
requirements for power and energy monitoring for networking devices 
are specified in [RFC6988]. Based on the requirements in [RFC6988], 
[RFC7326] presents a solution approach. 


Accordingly, the scope of the MIB modules in this document is in 
accordance to the requirements specified in [RFC6988] and the 
concepts from [RFC7326]. 


This document is based on the Energy Management Framework [RFC7326] 
and meets the requirements on identification of Energy Objects and 
their context and relationships as specified in the Energy Management 
requirements document [RFC6988]. 


A second MIB module meeting the EMAN requirements [RFC6988] the 
Monitoring and Control MIB for Power and Energy [RFC7460], monitors 
the Energy Objects for Power States, for the Power and Energy 


consumption. Power State monitoring includes: retrieving Power 
States, Power State properties, current Power State, Power State 
transitions, and Power State statistics. In addition, this MIB 


module provides the Power Characteristics properties of the Power and 
Energy, along with optional characteristics. 


The applicability statement document [EMAN-AS] provides the list of 
use cases, describes the common aspects between existing Energy 
standards and the EMAN standard, and shows how the EMAN framework 
relates to other frameworks. 


1.2. Conventions Used in This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
[RFC2119]. 

2. The Internet-Standard Management Framework 
For a detailed overview of the documents that describe the current 


Internet-Standard Management Framework, please refer to section 7 of 
RFC 3410 [RFC3410]. 
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4. 


Managed objects are accessed via a virtual information store, termed 
the Management Information Base or MIB. MIB objects are generally 
accessed through the Simple Network Management Protocol (SNMP). 
Objects in the MIB are defined using the mechanisms defined in the 
Structure of Management Information (SMI). This memo specifies MIB 
modules that are compliant with SMIv2, which is described in STD 58, 
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 
[RFC2580]. 


Terminology 


Please refer to [RFC7326] for the definitions of the following 
terminology used in this document. 


Energy Management 
Energy Management System (EnMS) 
Energy Monitoring 
Energy Control 
electrical equipment 
non-electrical equipment (mechanical equipment) 
device 

component 

power inlet 

power outlet 

energy 

power 

demand 

provide energy 
receive energy 
meter (energy meter) 
battery 

Power Interface 
Nameplate Power 
Power Attributes 
Power Quality 

Power State 

Power State Set 


Architecture Concepts Applied to the MIB Module 
This section describes the basic concepts specified in the Energy 


Management Framework [RFC7326], with specific information related to 
the MIB modules specified in this document. 
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The Energy Object Context 


Energy Object Context MIB 


(ENERGY-OBJECT-CONTEXT-MIB) 


March 2015 


MIB module in 


this document specifies MIB objects for the identification of Energy 
Objects and reporting context and relationship of an Energy Object. 


The managed objects are contained in two tables: 


eoRelationTable. 


The first table, 


modules, 


on identification, 
The second table, 
between Energy Objects. 
relationship between 


eoTable, 


eoRelationTable, 


Energy Objects. 


eoTable and 


focuses on the link to the other MIB 
and on the context of the Energy Object. 
Specifies the relationships 
This is a simplified representation of the 


A "smidump-style" tree presentation of the MIB modules contained in 


the document is presented. 


may 


"not-accessible"-»"---" 
"accessible-for-notify"-»"--n" 
"read-only"-»2"r-n" 
"read-write"-»"rwn" 


+- eoTable(1) 


+- eoEntry (1) 


1-- r-n 
1-- r-n 
1-- r-n 
+-- rwn 
1-- r-n 
1-- r-n 
1-- r-n 
1-- rwn 
+-- rwn 
+-- rwn 
+-- rwn 
1-- r-n 
+-- rwn 
1-- r-n 
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[entPhysicalIndex] 


PethPsePortIndexOrZero 
PethPsePortGroupIndexOrZero 
LldpPortNumberOrZero 
MacAddress 
InetAddressType 
InetAddress 

OCTET STRING 
SnmpAdminString 
SnmpAdminString 
EnergyObjectKeywordList 
Integer32 

INTEGER 

SnmpAdminString 

INTEGER 


Standards Track 


The meaning of the three symbols in is a 
compressed representation of the object's MAX-ACCESS clause, 
have the following values: 


which 


eoEthPortIndex(1) 
eoEthPortGrpIndex (2) 
eoLldpPortNumber (3) 
eoMgmtMacAddress (4) 
eoMgmtAddressType (5) 
eoMgmtAddress(6) 
eoMgmtDNSName (7) 
eoDomainName (8) 
eoRoleDescription(9) 
eoKeywords (10) 
eolImportance (11) 
eoPowerCategory (12) 
eoAlternateKey (13) 
eoPowerInterfaceType (14) 
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+- eoRelationTable (2) 


+- ror es [entPhysicalIndex, eoRelationIndex] 
t-- --n Integer32 eoRelationIndex(1) 
t-- rwn UUIDorZero eoRelationID (2) 
t-- rwn IANAEnergyRelationship eoRelationship (3) 
t-- rwn RowStatus eoRelationStatus (4) 
+-- rwn StorageType eoRelationStorageType (5) 


The following Unified Modeling Language (UML) diagram illustrates the 
relationship of the MIB objects in the eoTable, eoRelationTable, and 
ENTITY-MIB. The MIB objects describe the identity, context, and 
relationship of an Energy Object. The UML diagram, furthermore, 
contains objects from the ENTITY-MIB [RFC6933]. 
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eoRoleDescription 

eoKeywords | 
eoImportance | 
eoPowerCategory | 
eoPowerInterfaceType | 
eoDomainName | 


| entPhysicalIndex (*) | 
entPhysicalName (*) 

| entPhysicalUUID (*) | 
| entPhysicalClass (*) | 


| 
| 
| 
| 
| 
| 4------------------------------ + 
pus Link to other identifiers 
| | eoEthPortIndex (**) | 
| | eoEthPortGrpIndex (**) | 
| | eoLldpPortNumber (***) | 
| | eoMgmtMacAddress (optional) | 
eoMgmtAddressType (optional) 
| | eoMgmtAddress (optional) | 
| | eoMgmtDNSName (optional) | 
| | eoAlternateKey | 
| 4------------------------------ + 
| 4------------------------------ + 
---> | EO Relationship 
| eoRelationIndex | 
| eoRelationID | 
| eoRelationship | 
eoRelationStatus 
eoRelationStorageType 
SSS sSSSSSSs SS SSeS SS SSS SS SS Sse + 
(*) Compliance with entity4CRCompliance ENTITY-MIB [RFC6933] 


(**) Link with the Power over Ethernet MIB [RFC3621] 
(***) Link with LLDP MIBs [LLDP-MIB] [LLDP-MED-MIB] 


Figure 1: MIB Objects Grouping 
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As displayed in Figure 1, the MIB objects can be classified in 
different logical grouping of MIB objects. 


1) The Energy Object Identification. See Section 5.1 "Energy Object 
Identification". Devices and their sub-components are 
characterized by the power-related attributes of a physical entity 
present in the ENTITY-MIB [RFC6933]. 


2) The Context Information. See Section 4.1 "Energy Object Context". 


3) The links to other MIB modules. See Section 4.3 "Links to Other 
Identifiers". 


4) The Energy Object Relationships specific information. See Section 
4.4 "Energy Object Relationships". 


5) The Energy Object Identity Persistence. See Section 4.5 "Energy 
Object Identity Persistence". 


4.1. Energy Object Identification 


Refer to the "Identification" section in [RFC7326] for background 
information about Energy Objects. 


Every Energy Object MUST implement the unique index, 
entPhysicalIndex, entPhysicalName, entPhysicalClass, and 
entPhysicalUUID from the ENTITY-MIB [RFC6933]. Module Compliance 
with respect to entity4CRCompliance of ENTITY-MIB MUST be supported, 
which requires a limited number of objects supported 
(entPhysicallndex, entPhysicalName, entPhysicalClass, and 
entPhysicalUUID). entPhysicalIndex is used as index for the Energy 
Object in the ENERGY-OBJECT-CONTEXT-MIB module. Every Energy Object 
MUST have a printable name assigned to it. Energy Objects MUST 
implement the entPhysicalName object specified in the ENTITY-MIB 
[RFC6933], which must contain the Energy Object name. 


For the ENERGY-OBJECT-CONTEXT-MIB compliance, every Energy Object 
instance MUST implement the entPhysicalUUID from the ENTITY-MIB 
[RFC6933]. 


As displayed in [RFC4122], the following is an example of the string 
representation of a Universally Unique Identifier (UUID) as a URN: 
urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6. 


For example, to understand the relationship between Energy Object 


Components and Energy Objects, the ENTITY-MIB physical containment 
tree [RFC6933] MUST be implemented. 
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A second example deals with one of the ENTITY-MIB extensions: if the 
Energy Object temperature is required, the managed objects from the 
ENTITY-SENSOR-MIB [RFC3433] should be supported. 


Each Energy Object MUST belong to a single Energy Management Domain 
or in other words, an Energy Object cannot belong to more than one 
Energy Management Domain. Refer to the "Context: Domain" section in 
[RFC7326] for background information. The eoDomainName, which is an 
element of the eoTable, is a read-write MIB object. The Energy 
Management Domain should map 1:1 with a metered or sub-metered 
portion of the network. The Energy Management Domain MUST be 
configured on the Energy Object. The Energy Object MAY inherit some 
of the domain parameters (possibly domain name, some of the context 
information such as role or keywords, importance) from the Energy 
Object or the Energy Management Domain MAY be configured directly in 
an Energy Object. 


When an Energy Object acts as a Power Aggregator, the Energy Objects 
for which Power should be aggregated MUST be members of the same 
Energy Management Domain, specified by the eoDomainName MIB Object. 


4.2. Energy Object Context 


Refer to the "Context: Domain" section in [RFC7326] for background 
information. 


An Energy Object must provide a value for eoImportance in the range 
of 1-100 to help differentiate the use or relative value of the 


device. The importance range is from 1 (least important) to 100 
(most important). The default importance value is 1. 
An Energy Object can provide a set of eoKeywords. These keywords are 


a list of tags that can be used for grouping and summary reporting 
within or between Energy Management Domains. 


An Energy Object can have Power Interfaces and those interfaces can 
be classified as Power Inlet, Power Outlet, or both. 


An Energy Object can be classified based on the physical properties 
of the Energy Object. That Energy Object can be classified as 
consuming power or supplying power to other devices or that Energy 
Object can perform both of those functions and finally, an Energy 
Object can be a passive meter. 


Additionally, an Energy Object can provide an eoRoleDescription 


string that indicates the purpose the Energy Object serves in the 
network. 
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4.3. Links to Other Identifiers 


While the entPhysicalIndex is the primary index for all MIB objects 
in the ENERGY-OBJECT-CONTEXT-MIB module, the Energy Management 
Systems (EnMS) must be able to make the link with the identifier(s) 
in other supported MIB modules. 


If the Energy Object is a Power over Ethernet (PoE) port, and if the 
Power over Ethernet MIB [RFC3621] is supported by the SNMP agent 
managing the Energy Object, then the Energy Objects eoethPortIndex 
and eoethPortGrpIndex MUST contain the corresponding values of 
pethPsePortIndex and pethPsePortGroupIndex [RFC3621]. 


If the LLDP-MED MIB [LLDP-MIB] is supported by the Energy Object SNMP 
agent, then the Energy Object eoLldpPortNumber MUST contain the 
corresponding lldpLocPortNum from the LLDP MIB. 


The intent behind the links to the other MIB module identifier(s) is 
to correlate the instances in the different MIB modules. This will 
allow the ENERGY-OBJECT-CONTEXT-MIB module to reference other MIB 
modules in cases where the Power over Ethernet and the LLDP MIB 
modules are supported by the SNMP agent. Some use cases may not 
implement either of these two MIB modules for the Energy Objects. 
However, in situations where either of these two MIB modules are 
implemented, the EnMS must be able to correlate the instances in the 
different MIB modules. 


The eoAlternateKey object specifies an alternate key string that can 
be used to identify the Energy Object. Since an EnMS may need to 
correlate objects across management systems, this alternate key is 
provided to facilitate such a link. This optional value is intended 
as a foreign key or alternate identifier for a manufacturer or EnMS 
to use to correlate the unique Energy Object Id in other systems or 
namespaces. If an alternate key is not available or is not 
applicable, then the value is the zero-length string. 


An Energy Object can have additional MIB objects that can be used for 
easier identification by the EnMS. The optional objects 
eoMgmtMacAddress, eoMgmtAddressType, and eoMgmtDNSName can be used to 
help identify the relationship between the Energy Objects and other 
NMS objects. These objects can be used as an alternate key to help 
link the Energy Object with other keyed information that may be 
stored within the EnMS(s). For the optional objects that may not be 
included in some vendor implementations, the expected behavior when 
those objects are polled is a response noSuchInstance. 
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4.4. Energy Object Relationships 


Refer to the "Relationships" section in [RFC7326] for the definition 


and background information. In order to link two Energy Objects, a 
Separate table (eoRelationTable) has been introduced in this MIB 
module. 


Each Energy Object can have one or more Energy Object relationships 
with other Energy Objects. The relationship between Energy Objects 
is specified in eoRelationTable. The relationship between the Energy 
Objects is specified with the entPhysicallndex of the Energy Object 
and the UUID of the remote Energy Object. The UUID MUST comply to 
the RFC 4122 specifications. It is important to note that it is 
possible that an Energy Object may not have an Energy Object 
relationship with other Energy Objects. 


The following relationships between Energy Objects have been 
considered in the eoRelationTable. 


Metering Relationship -» meteredBy / metering 

Power Source Relationship -> poweredBy / powering 

Aggregation Relationship -> aggregatedBy / aggregating 
Energy Object B has a "meteredBy" relationship with Energy Object A, 
if the energy consumption of Energy Object B is measured by Energy 


Object A.  Equivalently, it is possible to indicate that Energy 
Object A has a "metering" relationship with Energy Object B. 


Energy Object B has a "poweredBy" relationship with Energy Object A, 
if the power source of Energy Object B is Energy Object A. 
Equivalently, it is possible to indicate that Energy Object A has a 
"powering" relationship with Energy Object B. 


Energy Object B has "aggregatedBy" relationship with Energy Object A, 
if Energy Object A is an aggregation point for energy usage of Energy 
Object B. Equivalently, it is possible to indicate that Energy 
Object A has "aggregating" relationship with Energy Object B. 


The IANA-ENERGY-RELATION-MIB module in Section 5 below specifies the 
first version of the IANA-maintained definitions of relationships. 
This way, for Energy Relationships, new textual conventions can be 
Specified, without updating the primary Energy Object Context MIB 
module. 
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4.5. Energy Object Identity Persistence 


In some situations, the Energy Object identity information should be 
persistent even after a device reload. For example, in a static 
setup where a switch monitors a series of connected PoE phones, there 
is a clear benefit for the EnMS if the Energy Object Identification 
and all associated information persist, as it saves a network 
discovery. However, in other situations, such as a wireless access 
point monitoring the mobile user PCs, there is not much advantage to 
persist the Energy Object Information. The identity information of 
an Energy Object should be persisted and there is value in the 
writable MIB objects persisted. 


5. MIB Definitions 


—— KK KK KKK ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ckck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck kk k k k kk 


-- This MIB is used for describing the identity and the 
-- context information of Energy Objects in network 


—— o Ckckckck ck ck ck ck ckck k ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ckck ck ckck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck k kc k k k kk 


ENERGY-OBJECT-CONTEXT-MIB DEFINITIONS ::- BEGIN 


IMPORTS 
MODULE-IDENTITY, 
OBJECT-TYPE, 
mib-2, Integer32 


FROM SNMPv2-SMI -- RFC 2578 
TEXTUAL-CONVENTION, MacAddress, TruthValue, 

RowStatus, StorageType 

FROM SNMPv2-TC -- RFC 2579 
MODULE-COMPLIANCE, OBJECT-GROUP 

FROM SNMPv2-CONF -- RFC 2580 
SnmpAdminString 

FROM SNMP-FRAMEWORK-MIB -- RFC 3411 
InetAddressType, InetAddress 

FROM INET-ADDRESS-MIB -- RFC 4001 
entPhysicalIndex 

FROM ENTITY-MIB -- RFC 6933 
UUIDorZero 

FROM UUID-TC-MIB -- RFC 6933 


IANAEnergyRelationship 
FROM IANA-ENERGY-RELATION-MIB; 


Parello, et al. Standards Track [Page 12] 


RFC 7461 Energy Object Context MIB March 2015 


energyObjectContextMIB MODULE-IDENTITY 


LAST-UPDATED "201502090000z" 
ORGANIZATION "IETF EMAN Working Group" 
CONTACT-INFO 

"WG Charter: 


http://datatracker.ietf.org/wg/eman/charter/ 


Mailing Lists: 

General Discussion: eman@ietf.org 

To Subscribe: https://www.ietf.org/mailman/listinfo/eman 
Archive: http://www.ietf.org/mail-archive/web/eman 


Editors: 
John Parello 
Cisco Systems, Inc. 
3550 Cisco Way 
San Jose, California 95134 
United States 
Phone: +1 408 525 2339 
Email: jparello@cisco.com 


Benoit Claise 

Cisco Systems, Inc. 

De Kleetlaan 6a bl 

Degem 1831 

Belgium 

Phone: +32 2 704 5622 
Email: bclaise@cisco.com 


Mouli Chandramouli 

Cisco Systems, Inc. 
Sarjapur Outer Ring Road 
Bangalore 560103 

India 

Phone: +91 80 4429 2409 
Email: moulchan@cisco.com" 


DESCRIPTION 
"Copyright (c) 2015 IETF Trust and the persons identified as 
authors of the code. All rights reserved. 


Redistribution and use in source and binary forms, with or 
without modification, is permitted pursuant to, and subject 
to the license terms contained in, the Simplified BSD License 
set forth in Section 4.c of the IETF Trust's Legal Provisions 
Relating to IETF Documents 
(http://trustee.ietf.org/license-info). 
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This MIB is used for describing the identity and the 
context information of Energy Objects." 
REVISION 
"2015020900002" 
DESCRIPTION 
"Initial version, published as RFC 7461." 


:= { mib-2 231 } 


energyObjectContextMIBNotifs OBJECT IDENTIFIER 
::— ( energyObjectContextMIB 0 } 


energyObjectContextMIBObjects OBJECT IDENTIFIER 
::— ( energyObjectContextMIB 1 } 


energyObjectContextMIBConform OBJECT IDENTIFIER 
::— ( energyObjectContextMIB 2 } 


-— Textual Conventions 


PethPsePortIndexOrZero ::- TEXTUAL-CONVENTION 
DISPLAY-HINT "d" 
STATUS current 
DESCRIPTION 


"This textual convention is an extension of the 
pethPsePortIndex convention, which defines a greater- 
than-zero value used to identify a power Ethernet Power 
Sourcing Equipment (PSE) port. 


This extension permits the additional value of zero. The 
semantics of the value zero are object-specific and must, 
therefore, be defined as part of the description of any 
object that uses this syntax. Examples of the usage of 
this extension are situations where none or all physical 
entities need to be referenced." 

SYNTAX Integer32 (0..2147483647) 


PethPsePortGroupIndexOrZero ::= TEXTUAL-CONVENTION 
DISPLAY-HINT "d" 
STATUS current 
DESCRIPTION 


"This textual convention is an extension of the 
pethPsePortGroupIndex convention from the Power Over 

Ethernet MIB in RFC 3621, which defines a greater-than-zero 
value used to identify the group containing the port to which 
a power Ethernet PSE is connected. This extension 

permits the additional value of zero. The semantics of 

the value zero are object-specific and must, therefore, 
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be defined as part of the description of any object that 
uses this syntax. Examples of the usage of this 
extension are situations where none or all physical 
entities need to be referenced." 

SYNTAX Integer32 (0..2147483647) 


LidpPortNumberOrZero ::= TEXTUAL-CONVENTION 

DISPLAY-HINT "d" 

STATUS current 

DESCRIPTION 
"This textual convention is an extension of the 
LldpPortNumber convention specified in the LLDP MIB, 
which defines a greater than zero value used to uniquely 
identify each port contained in the chassis (that is 
known to the LLDP agent) by a port number. This 
extension permits the additional value of zero. The 
semantics of the value zero are object-specific and must, 
therefore, be defined as part of the description of any 
object that uses this syntax. Examples of the usage of 
this extension are situations where none or all physical 
entities need to be referenced." 

SYNTAX Integer32(0..4096) 


EnergyObjectKeywordList ::= TEXTUAL-CONVENTION 

STATUS current 

DESCRIPTION 
"A list of keywords that can be used to group Energy 
Objects for reporting or searching. If multiple keywords 
are present, then this string will contain all the 
keywords separated by the ',' character. All alphanumeric 
characters and symbols (other than a comma), such as 4, 
(, $, !, and &, are allowed. White spaces before and 
after the commas are ignored, as well as within a keyword 
itself. 


For example, if an Energy Object were to be tagged with 
the keyword values 'hospitality' and 'guest', then the 
keyword list will be 'hospitality,guest'." 

SYNTAX OCTET STRING (SIZE (0..2048)) 


-- Objects 


eoTable OBJECT-TYPE 


SYNTAX SEQUENCE OF EoEntry 
MAX-ACCESS not-accessible 
STATUS current 

DESCRIPTION 


"This table lists Energy Objects." 
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::= { energyObjectContextMIBObjects 1 } 


eoEntry OBJECT-TYPE 


SYNTAX EoEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 


"An entry describes the attributes of an Energy Object. 
Whenever a new Energy Object is added or an existing 
Energy Object is deleted, a row in the eoTable is added 
or deleted." 


INDEX (entPhysicallIndex ) 
::= ( eoTable 1 } 


EoEntry ::= SEQUENCE { 
eoEthPortIndex PethPsePortIndexOrZero, 
eoEthPortGrpIndex PethPsePortGroupIndexOrZero, 
eoLldpPortNumber LldpPortNumberOrZero, 
eoMgmtMacAddress MacAddress, 
eoMgmtAddressType InetAddressType, 
eoMgmtAddress InetAddress, 
eoMgmtDNSName OCTET STRING, 
eoDomainName SnmpAdminString, 
eoRoleDescription SnmpAdminString, 
eoKeywords EnergyObjectKeywordList, 
eoImportance Integer32, 
eoPowerCategory INTEGER, 
eoAlternateKey SnmpAdminString, 
eoPowerInterfaceType INTEGER 


} 


eoEthPort Index OBJECT-TYPE 
SYNTAX PethPsePortIndexOrZero 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


Parello, 


et al. 


"This variable uniquely identifies the power Ethernet 


port to which a Power over 


Ethernet device is connected. 


If the Power over Ethernet MIB in RFC 3621 is supported by 
the SNMP agent managing the Energy Object, 


then the 


Energy Object eoethPortIndex MUST contain the 


corresponding value of pethPsePortIndex. 
Ethernet port cannot be specified or is not known, 


the object is zero." 


REFERENCE 


"RFC 3621: 


DEFVAL { 0 } 


Standards Track 


then 


Power Ethernet MIB" 


If such a power 
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::= ( eoEntry 1 } 


eoEthPortGrpIndex OBJECT-TYPE 


SYNTAX PethPsePortGroupIndexOrZero 
MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 


"This variable uniquely identifies the group containing 
the port to which a power over Ethernet device PSE is 
connected (RFC 3621). If the Power over Ethernet MIB (RFC 
3621) is supported by the SNMP agent managing the Energy 
Object, then the Energy Object eoEthPortGrpIndex MUST 
contain the corresponding value of eoethPortGrpIndex. If 
such a power Ethernet port cannot be specified or is not 
known, then the object is zero." 

REFERENCE 
"RFC 3621: Power Ethernet MIB" 

DEFVAL ( 0 } 

::— ( eoEntry 2 } 


eoLldpPortNumber OBJECT-TYPE 


SYNTAX LldpPortNumberOrZero 
MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 


"This variable uniquely identifies the port component 
(contained in the local chassis with the LLDP agent) as 
defined by the lldpLocPortNum in the LLDP-MIB and 
LLDP-MED-MIB. If the LLDP-MIB is supported by the 
SNMP agent managing the Energy Object, then the Energy 
Object eoLldpPortNumber MUST contain the corresponding 
value of lldpLocPortNum from the LLDP-MIB. If such a 
port number cannot be specified or is not known, then the 
object is zero." 
REFERENCE 
"LLDP MIB, IEEE 802.1AB-2005; LLDP-MED-MIB, ANSI/TIA-1057" 
DEFVAL { 0 } 


::= { eoEntry 3 } 


eoMgmtMacAddress OBJECT-TYPE 


SYNTAX MacAddress 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"This object specifies a Media Access Control (MAC) address 
of the Energy Object." 
::= { eoEntry 4 } 
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eoMgmtAddressType OBJECT-TYPE 


SYNTAX InetAddressType 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"This object specifies the eoMgmtAddress type, i.e., an 
IPv4 or IPv6 address. This object MUST be 
populated when eoMgmtAddress is populated." 

::— { eoEntry 5 } 


eoMgmtAddress OBJECT-TYPE 


SYNTAX InetAddress 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"This object specifies the management address as an IPv4 

address or IPv6 address of Energy Object. The IP address 

type, i.e. IPv4 or IPv6, is determined by the 

eoMgmtAddressType value. This object can be used as an 

alternate key to help link the Energy Object with other 

keyed information that may be stored within the EnMS(s)." 
:= { eoEntry 6 } 


eoMgmtDNSName OBJECT-TYPE 


SYNTAX OCTET STRING 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"This object specifies a DNS name of the eoMgmtAddress. 
This object can be used as an alternate key to help link 
the Energy Object with other keyed information that may 


be stored within the EnMS(s). A DNS Name must always be a 
fully qualified name. This MIB uses the same encoding as 
the DNS protocol." 

REFERENCE 
"RFC 1034: Domain names - concepts and facilities, 


Section 3.1." 
::= ( eoEntry 7 } 


eoDomainName OBJECT-TYPE 


SYNTAX SnmpAdminString 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 


"This object specifies the name of an Energy Management 
Domain for the Energy Object. By default, this object 
should be an empty string. The value of eoDomainName must 
remain constant at least from one re-initialization of 
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the entity local management system to the next re- 
initialization." 
::= ( eoEntry 8 } 


eoRoleDescription OBJECT-TYPE 


SYNTAX SnmpAdminString 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 


"This object specifies an administratively assigned name 
to indicate the purpose an Energy Object serves in the 
network. 


For example, we can have a phone deployed to a lobby with 
eoRoleDescription as 'Lobby phone’. 


This object specifies that the value is the zero-length 
string value if no role description is configured. 
The value of eoRoleDescription must remain constant at 
least from one re-initialization of the entity local 
management system to the next re-initialization." 

:= ( eoEntry 9 } 


eoKeywords OBJECT-TYPE 


SYNTAX EnergyObjectKeywordList 
MAX-ACCESS read-write 

STATUS current 

DESCRIPTION 


"This object specifies a list of keywords that can be 
used to group Energy Objects for reporting or searching. 
The value is the zero-length string if no keywords have 
been configured. If multiple keywords are present, then 
this string will contain all the keywords separated by 
the ',' character. For example, if an Energy Object were 
to be tagged with the keyword values 'hospitality' and 
'guest', then the keyword list will be 
'hospitality,guest'. 


If write access is implemented and a value is written 
into the instance, the agent must retain the supplied 
value in the eoKeywords instance associated with 
the same physical entity for as long as that entity 
remains instantiated. This includes instantiations 
across all re-initializations/reboots of the local 
management agent." 

::— ( eoEntry 10 } 


eolmportance OBJECT-TYPE 
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SYNTAX Integer32 (1..100) 
MAX-ACCESS read-write 

STATUS current 
DESCRIPTION 


"This object specifies a ranking of how important the 
Energy Object is (on a scale of 1 to 100) compared with 
other Energy Objects in the same Energy Management 
Domain. The ranking should provide a business or 
operational context for the Energy Object as compared to 
other similar Energy Objects. This ranking could be used 
as input for policy-based network management. 


Although network managers must establish their own 
ranking, the following is a broad recommendation: 


90 to 100 Emergency response 
80 to 89 Executive or business critical 
70 to 79 General or average 
60 to 69 Staff or support 
40 to 59 Public or guest 
1 to 39 Decorative or hospitality 


The value of eoImportance must remain constant at least 
from one re-initialization of the Energy Object local 
management system to the next re-initialization." 
DEFVAL [2-2 
::— ( eoEntry 11 H 


eoPowerCategory OBJECT-TYPE 
SYNTAX INTEGER { 
consumer (0), 
producer(1), 
meter(2), 
distributor(3), 


store(4) 
} 
MAX-ACCESS read-only 
STATUS current 


DESCRIPTION 
"This object describes the Energy Object category, which 
indicates the expected behavior or physical property of 
the Energy Object, based on its design. An Energy Object 
can be a consumer(0), producer(1), meter(2), 
distributor(3), or store(4). 


In some cases, a meter is required to measure the power 
consumption. In such a case, this meter Energy Object 
category is meter(2). If a device is distributing 
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electric Energy, the category of the Energy Object is 


distributor (3). If a device is storing electric Energy, 
the category of the device can be store (4)." 
::— ( eoEntry 12 ) 


eoAlternateKey OBJECT-TYPE 


SYNTAX SnmpAdminString 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 


"The eoAlternateKey object specifies an alternate key 
string that can be used to identify the Energy Object. 
Since Energy Management Systems (EnMS) and Network 
Management Systems (NMSs) may need to correlate objects 
across management systems, this alternate key is provided 
to provide such a link. This optional value is intended 
as a foreign key or alternate identifier for a 
manufacturer or EnMS/NMS to use to correlate the unique 
Energy Object Id in other systems or namespaces. If an 
alternate key is not available or is not applicable, then 
the value is the zero-length string. 
The value of eoAlternateKey must remain constant at 
least from one re-initialization of the entity local 
management system to the next re-initialization." 

::— ( eoEntry 13 } 


eoPowerInterfaceType OBJECT-TYPE 
SYNTAX INTEGER { 
inlet(0), 
outlet(1), 
both (2) 
} 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"This object describes the Power Interface for an Energy 
Object. A Power Interface is an interface at which an 
Energy Object is connected to a power transmission 
medium, at which it can in turn receive power, provide 
power, or both. A Power Interface type can be an inlet(0), 
an outlet(1), or both(2), respectively." 

::— ( eoEntry 14 } 


eoRelationTable OBJECT-TYPE 


SYNTAX SEQUENCE OF EoRelationEntry 
MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 
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"This table describes the relationships between Energy 


Objects." 
::= { energyObjectContextMIBObjects 2 } 


eoRelationEntry OBJECT-TYPE 


SYNTAX EoRelationEntry 

MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 
"An entry in this table specifies the Energy relationship 
between Energy objects. Energy relations between two 
Energy objects are defined in RFC 7326." 

REFERENCE 
" RFC 7326: Energy Management Framework" 

INDEX { entPhysicallndex, eoRelationIndex } 


::— { eoRelationTable 1 } 


EoRelationEntry ::= SEQUENCE { 
eoRelationIndex Integer32, 
eoRelationID UUIDorZero, 
eoRelationship IANAEnergyRelationship, 
eoRelationStatus RowStatus, 


eoRelationStorageType StorageType 
} 


eoRelationIndex OBJECT-TYPE 
SYNTAX Integer32 (0..2147483647) 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 


"This object is an arbitrary index to identify the Energy 
Object related to another Energy Object." 
::= { eoRelationEntry 1 } 


eoRelationID OBJECT-TYPE 
SYNTAX UUIDorZero 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 


"This object specifies the Universally Unique Identifier 
(UUID) of the peer (other) Energy Object. The UUID must 
comply with the specifications of UUID in UUID-TC-MIB. 


If the UUID of the Energy Object is unknown or nonexistent, 
the eoRelationID will be set to a zero-length string 
instead. It is preferable that the value of 
entPhysicalUUID from ENTITY-MIB is used for values for 
this object." 
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REFERENCE 
"RFC 6933: Entity MIB (Version 4)" 
::= ( eoRelationEntry 2 } 


eoRelationship OBJECT-TYPE 
SYNTAX IANAEnergyRelationship 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"This object describes the relations between Energy 
Objects. For each Energy Object, the relations between 


the other Energy Objects are specified using the bitmap." 
::= { eoRelationEntry 3 } 


eoRelationStatus OBJECT-TYPE 


SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 


"The status controls and reflects the creation and 
activation status of a row in this table to specify energy 
relationship between Energy Objects. 


An entry status may not be active(1) unless all objects in 
the entry have the appropriate values. 


No attempt to modify a row columnar object instance value 
in the eoRelationTable should be issued while the value of 
eoRelationStatus is active(1). The data can be destroyed by 
setting up the eoRelationStatus to destroy(2)." 

::= ( eoRelationEntry 4 } 


eoRelationStorageType OBJECT-TYPE 


SYNTAX StorageType 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 


"This variable indicates the storage type for this row." 
DEFVAL { nonVolatile } 
::= {eoRelationEntry 5 } 


-—— Conformance 


energyObjectContextMIBCompliances OBJECT IDENTIFIER 
::= { energyObjectContextMIBConform 1 } 


energyObjectContextMIBGroups OBJECT IDENTIFIER 
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::= { energyObjectContextMIBConform 2 } 


energyObjectContextMIBFullCompliance MODULE-COMPLIANCE 

STATUS current 

DESCRIPTION 
"When this MIB is implemented with support for 
read-write, then such an implementation can 
claim full compliance. Such devices can then 
be both monitored and configured with this MIB. 
Module Compliance of ENTITY-MIB with respect to 
entity4CRCompliance MUST be supported." 


MODULE -- this module 
MANDATORY-GROUPS { 
energyObjectContextMIBTableGroup, 
energyObjectRelationTableGroup 
} 


GROUP energyObjectOptionalMIBTableGroup 
DESCRIPTION 
"A compliant implementation does not have to 
implement." 

::— ( energyObjectContextMIBCompliances 1 } 


energyObjectContextMIBReadOnlyCompliance MODULE-COMPLIANCE 

STATUS current 

DESCRIPTION 
"When this MIB is implemented without support for 
read-write (i.e., in read-only mode), then such an 
implementation can claim read-only compliance. 
Such a device can then be monitored but cannot be 
configured with this MIB. 
Module Compliance of ENTITY-MIB with respect to 
entity4CRCompliance MUST be supported." 

MODULE -- this module 


MANDATORY-GROUPS { 
energyObjectContextMIBTableGroup, 
energyObjectRelationTableGroup 
} 
GROUP energyObjectOptionalMIBTableGroup 
DESCRIPTION 
"A compliant implementation does not have to implement 
the managed objects in this GROUP." 


::= { energyObjectContextMIBCompliances 2 } 
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-- Units of Conformance 
energyObjectContextMIBTableGroup OBJECT-GROUP 
OBJECTS { 
eoDomainName, 
eoRoleDescription, 
eoAlternateKey, 
eoKeywords, 
eoImportance, 
eoPowerCategory, 
eoPowerInterfaceType 
} 
STATUS current 
DESCRIPTION 
"This group contains the collection of all the objects 
related to the EnergyObject." 


::— { energyObjectContextMIBGroups 1 } 


energyObjectOptionalMIBTableGroup OBJECT-GROUP 
OBJECTS { 
eoEthPortIndex, 
eoEthPortGrpIndex, 
eoLldpPortNumber, 
eoMgmtMacAddress, 
eoMgmtAddressType, 
eoMgmtAddress, 
eoMgmtDNSName 
} 
STATUS current 
DESCRIPTION 
"This group contains the collection of all the objects 
related to the Energy Object." 
::= { energyObjectContextMIBGroups 2 } 


energyObjectRelationTableGroup OBJECT-GROUP 
OBJECTS { 


eoRelationID, 
eoRelationship, 
eoRelationStatus, 
eoRelationStorageType 
} 
STATUS current 
DESCRIPTION 
"This group contains the collection of all objects 
specifying the relationship between Energy Objects." 
::— { energyObjectContextMIBGroups 3 } 
END 
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IANA-ENERGY-RELATION-MIB DEFINITIONS ::= BEGIN 
IMPORTS 
MODULE-IDENTITY, mib-2 
FROM SNMPv2-SMI 
TEXTUAL-CONVENTION 
FROM SNMPv2-TC; 


ianaEnergyRelationMIB MODULE-IDENTITY 
LAST-UPDATED "2015020900002" -- February 9, 2015 
ORGANIZATION "IANA" 
CONTACT-INFO " 
Internet Assigned Numbers Authority 
Postal: ICANN 
12025 Waterfront Dr., Suite 300 
Los Angeles, CA 90094 
United States 
Tel: -1-310-301-5800 
EMail: iana@iana.org" 


DESCRIPTION 
"Copyright (c) 2015 IETF Trust and the persons identified as 
authors of the code. All rights reserved. 


Redistribution and use in source and binary forms, with or 
without modification, is permitted pursuant to, and subject 
to the license terms contained in, the Simplified BSD 
License set forth in Section 4.c of the IETF Trust's Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info). 


This MIB module defines a TEXTUAL-CONVENTION that 
describes the relationships between Energy Objects. 


The initial version of this MIB module was published in 
RFC 7461; for full legal notices see the RFC itself." 


REVISION "2015020900002" -- February 9, 2015 

DESCRIPTION "Initial version of this MIB as published in 
RFC 7461." 

::= { mib-2 232 ] 


-— Textual Conventions 


IANAEnergyRelationship ::- TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 


"An enumerated value specifying the type of 
relationship between an Energy Object A, on 
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which the relationship is specified, with the 
Energy Object B, identified by the UUID. 


The enumeration 'poweredBy' is applicable if 
Energy Object A is poweredBy Energy Object B. 


The enumeration 'powering' is applicable if 
Energy Object A is powering Energy Object B. 


The enumeration 'meteredBy' is applicable if 
Energy Object A is meteredBy Energy Object B. 


The enumeration 'metering' is applicable if 
Energy Object A is metering Energy Object B. 


The enumeration 'aggregatedBy' is applicable if 
Energy Object A is aggregatedBy Energy Object B. 


The enumeration 'aggregating' is applicable if 
Energy Object A is aggregating Energy Object B." 


SYNTAX INTEGER { 
poweredBy (1), -- power relationship 

powering(2), 

meteredBy (3), -- meter relationship 

metering (4) 

aggregatedB 

aggregating 

} 


5), -- aggregation relationship 
) 


END 
6. Security Considerations 


There are a number of management objects defined in this MIB module 
with a MAX-ACCESS clause of read-write and/or read-create. Such 
objects may be considered sensitive or vulnerable in some network 
environments. The support for SET operations in a non-secure 
environment without proper protection opens devices to attack. These 
are the tables and objects and their sensitivity/vulnerability: 


Unauthorized changes to the eoDomainName, entPhysicalName, 
eoRoleDescription, eoKeywords, eoImportance, eoAlternateKey, 
eoRelationID, eoRelationship, eoRelationStatus, and/or 
eoRelationStorageType MAY disrupt power and energy collection, and 
therefore any predefined policies defined in the network. 
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SNMP versions prior to SNMPv3 did not include adequate security. 
Even if the network itself is secure (for example by using IPsec), 
there is no control as to who on the secure network is allowed to 
access and GET/SET (read/change/create/delete) the objects in this 
MIB module. 


Implementations SHOULD provide the security features described by the 
SNMPv3 framework (see [RFC3410]), and implementations claiming 
compliance to the SNMPv3 standard MUST include full support for 
authentication and privacy via the User-based Security Model (USM) 
[RFC3414] with the AES cipher algorithm [RFC3826].  Implementations 
MAY also provide support for the Transport Security Model (TSM) 
[RFC5591] in combination with a secure transport such as SSH 
[RFC5592] or TLS/DTLS [RFC6353]. 


Further, deployment of SNMP versions prior to SNMPv3 is NOT 
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 
enable cryptographic security. It is then a customer/operator 
responsibility to ensure that the SNMP entity giving access to an 
instance of this MIB module is properly configured to give access to 
the objects only to those principals (users) that have legitimate 
rights to indeed GET or SET (change/create/delete) them. 


In certain situations, energy and power monitoring can reveal 
sensitive information about individuals’ activities and habits. 
Implementors of this specification should use appropriate privacy 
protections as discussed in Section 9 of RFC 6988 and monitoring of 
individuals and homes should only occur with proper authorization. 


7. IANA Considerations 


The MIB modules in this document use the following IANA-assigned 
OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 


Descriptor OBJECT IDENTIFIER Value 


energyObjectContextMIB ( mib-2 231 } 


This document defines the first version of the IANA-maintained IANA- 
ENERGY-RELATION-MIB module, which allows new definitions of 
relationships between Energy Objects. 


A Specification Required as defined in [RFC5226] is REQUIRED for each 
modification of the energy relationships. 


The MIB module in this document uses the following IANA-assigned 
OBJECT IDENTIFIER values recorded in the SMI Numbers registry. 
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Descriptor OBJECT IDENTIFIER Value 
ianaEnergyRelationMIB /— (mib-2 232)  — 
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